In a Java™ application server environment, users may manage resources, such as nodes (i.e., computer systems), servers, applications, and clusters (i.e., collection of application servers), belonging, for example, to an organization, by logging onto a network in communication with the resources. Typically, the logon requires a security process, such as verification of a user identifier and password, before a user can access the resources. After network verification, the user has access to all the resources on the network.
Before conducting any resource management, such as stopping and starting a server, tuning a server, reading a log file on a node, and so forth, the application may also require a security process for a user to log into the application. The security process may be the same or similar to the user identifier and password required for logging onto the network. Now, after verification, the user has access to all the resources, which the user may manage in an unfettered manner.
However, organizations may hesitate at granting unfettered access to users for managing resources on the network in order to prevent security breaches, such as infiltration and corruption, as well as to ensure proper management, such as configuration, administration, operation, and monitoring of the resources. To restrict access, additional security processes are implemented. Implementing additional processes requires additional constraints placed on both the user and/or the resource. These additional constraints are collectively termed “fine-grained authorization,” as opposed to the “coarse-grained authorization,” or generalized authorization, described above in terms of verification of user identifier and password. Solutions for providing restricted access have relied upon, for example, conventional role and policy based authorization systems in order to determine whether a user has access rights to perform a requested action on a particular resource before allowing the user to perform the requested action, i.e., attempt to manage the resource.
Turning now to discussion of the Java™ application server environment, Java Management Extension (“JMX™”) provides a set of remote application programmer interfaces (APIs) for managing and monitoring remote resources. A managed application server systems, such as an mbean server application, incorporates the JMX APIs, and provides a set of mbeans, an abbreviation for management beans comprising small pieces of JAVA™ code, to perform the management operations on the resource, wherein the operations comprise a set of actions. Before invoking an mbean method to perform any action on a resource instance, the aforementioned authority for the user to perform the requested action is required to ensure the user has such authority.
Prior solutions sometimes use one mbean for each resource instance, and viewed in combination with whether a user has an authority to perform the requested action on a resource, then a one-to-one relation exists between mbeans and authority checks; therefore, a thousand files of authority to mbean invocation methods for a thousand resources—a horrendous scalability issue for a large organization. Further, even if reduction of the scalability issue results by providing only one mbean for each resource type, such as servers, nodes, etc., then identity of multiple instances of a resource is unsolved, whether or not the user has access or not to perform the requested action on the resource. By using one mbean for each resource type, and providing methods, systems, and media for uniquely identifying each resource type, followed by checking for authorization to perform the requested action on the uniquely identified resource, then fine-grained authorization occurs with simultaneous optimization of scalability, and therein, reduction of storage requirements for implementation of the fine-grained authorization.